Cloned from bug 1935331.

Error - Inbox on vseerror@xxxx.edu
The folder 'Inbox on vseerror@xxxx.edu' could not be compacted because writing to folder failed. Verify that you have enough disk space, and that you have write privileges to the file system, then try again.

This occurred with 138.0b1, on macbook with a profile a few months old with my three primary imap accounts, plus the account which errored [1]. I think I have never compacted this profile - I had auto compact enabled but set to prompt. I removed the prompt requirement, started Thunderbird, and got the error during the compact process.

[1] This particular account vseerror@xxxx.edu "should" have no corruption because the account has no filters, and no messages would have been deleted or moved into it's folders. In other words all the messages would have been downloaded via imap autosync - message sync is enabled. One oddity is the account hasn't been logged into for approximately two months, because the account is gone from the server.

This was found in the process of researching Bug 1952311 - All messages in all folders no longer visible - disappear (don't display) when compacting (auto compact) - shows only after restart - I encountered the following during automatic compact.

Forgot to mention, when the error occurs on startup, the selected folder is not from xxxx.edu account. And afaict there is no attempt by Thunderbird to log in to the account.

This is very reproducible. And even if there is "nothing" to compact - after a few startups the compact still occurs, and ends with "Done compacting (approx. xxxkb saved)". The value for amount saved is no where near the set compact threshold.

Is this a new regression?

Sounds pretty serious, let's upgrade priority until we understand better.

Do you have STR with a fresh account?

Can anyone else reproduce?

(In reply to Kai Engert [:KaiE:] from comment #2)

Is this a new regression?

Sorry, no idea how old. This particular profile is many months old, and I never had allowed compact to occur until I reported the bug.

I do not have better steps. Notable however, is the the fact that the account it fails on cannot be logged in to, the account no longer exists. If that is the precondition, then I wouldn't consider this to be a very severe bug.

Hello!

We have tried to reproduce this issue on
138.0b1( 20250403012914), 138.0b2(20250410152641) and 128.9.1esr(20250404032315) on macOS Sonoma and unfortunately we couldn’t reproduce the error on any of our accounts.

I'm citing some SUMO articles, but some might have been solved by 128.7.0. I'll have to ask them for feedback.

I might have a clue which helps to reproduce that error. I am on Arch Linux, running 137.0.2. During "normal" operation i do not get those errors. However, i get them quite regularly after i wake the laptop up from suspend - and if there is a change in network connection

The wifi which i use during the train ride vanishes, and it takes a few seconds for the ethernet connection in the dock to take over. The "could not be compacted because writing to folder failed" error is already there before network manager announces the switch to the ethernet connection.

Maybe one can reproduce the problem by turning wifi off and use an ethernet connection, then send the laptop to sleep, unplug the ethernet and wait a few minutes before waking up (so that enough time passes that thunderbird will start a compact run).

Thanks to everyone working on thunderbird, have a nice day,
Michael

Thanks, Wayne and Michael - I'm assuming these are IMAP accounts?

I can't reproduce it via a manual compaction - I'm guessing it only happens with autocompact on IMAP accounts, when the server cannot be reached.
Compaction on IMAP also issues an EXPUNGE to the server, and I'm guessing this is what causes the error message.
The fact that the "Done compacting (approx. xxxkb saved)" status message is displayed seems to hint that the local mbox compaction is happening OK. Although maybe the EXPUNGE fail means that the folders expunge counter isn't being correctly updated, hence what you see in comment #1.
I don't think there's anything too serious going on here - just bad coordination between the compact and IMAP EXPUNGE error reporting.

I'll step through the autocompaction code and see what I can see.
The question is: what should the user be told if the local compaction can happen but not the IMAP EXPUNGE? It should be a "can't connect to server error", but I'm inclined to think the error should just be suppressed (or displayed in the status bar) rather than a popup...

Gah. Stalled with Bug 1962927. Will get back to you!

Hmm. I can't replicate this.
I tried by reducing the auto-compact thresholds to 0s delay and 0MB in code, so I can trigger autocompact at will via the "Get Messages" button.

I then deleted a few messages (which also triggers autocompaction, which worked fine).

I then turned off my IMAP server and triggered autocompact (via "Get Messages"), clicked "compact" on to the autocompact confirmation prompt, and it still worked fine.
(The "Get Messages" didn't complain that it couldn't connect to the server, which seems a little odd, but probably unrelated?)

So I don't know how to trigger this.

In any case, the compact log covers autocompaction (somewhat), so running with MOZ_LOG="compact:5" might shed some light? If not I'll add some more logging in to cover the result of IMAP EXPUNGE part of the compaction (the mbox compaction doesn't proceed until the EXPUNGE is completed).

(In reply to Ben Campbell from comment #8)

I don't think there's anything too serious going on here - just bad coordination between the compact and IMAP EXPUNGE error reporting.

In general i would agree, but that error is currently something that i see 3-4 times a day, so it depends on the usecase i guess. Also, this error message is shown every time i hit bug 1952311 - and this bug needs either reopening the folders in a new tab or a restart of thunderbird.

I will start thunderbird with MOZ_LOG="compact:5" , and report back soon. My guess is that i will see that error once i leave the train i am currently in ;)

Thanks for your work,
Michael

(In reply to brot+mozillabt from comment #11)

In general i would agree, but that error is currently something that i see 3-4 times a day, so it depends on the usecase i guess. Also, this error message is shown every time i hit bug 1952311 - and this bug needs either reopening the folders in a new tab or a restart of thunderbird.

Well, during the trainride i just hit #1952311 and did not get the error message. So it may not be everytime.

(In reply to brot+mozillabt from comment #7)

I might have a clue which helps to reproduce that error. I am on Arch Linux, running 137.0.2. During "normal" operation i do not get those errors. However, i get them quite regularly after i wake the laptop up from suspend - and if there is a change in network connection

Ahh, it looks like 137 didn't include a big chunk of the compaction changes I thought it did (see https://bugzilla.mozilla.org/show_bug.cgi?id=1925117#c37 ).
That said, Wayne said he hit it on 138.0b1, which as far as I can tell does have all the changes from Bug 1925117 ...

Hmm. Catching it in the logging should give some clues, and in the meantime I'm going to keep trying to replicate it locally.

(In reply to brot+mozillabt from comment #11)

(In reply to Ben Campbell from comment #8)

I don't think there's anything too serious going on here - just bad coordination between the compact and IMAP EXPUNGE error reporting.

In general i would agree, but that error is currently something that i see 3-4 times a day, so it depends on the usecase i guess.

Sorry, yes - I didn't mean to imply it wasn't a complete pain in the neck :-)

I'm thinking this might be the same as Bug 1960105.

My prediction: the compaction logs will have errors like this:

"E/compact BatchCompactor - Can't compact 'imap://blah@blah/blah/blah' now. Queued for retry."

Which indicates the compaction is refusing to proceed for the folder because of being IMAP pseudoOps or offline ops.

Steps-to-replicate over at: bug 1960105 comment 21

Is there any update on this bug? Any idea if this is widespread or isolated?

Having to close and restart TB several times every day is a real PITB...

There's been progress on bug 1960105 which may be the same

I'm getting the same error message using Tbird 138.0 on Win 11 upon opening Tbird.

The fix from Bug 1960105 is going into 139 and I'm reasonably sure this is the same issue.
139 is currently in the beta channel.

I also have this bug sometimes on startup in version 138.0.1 (Win11).

I have this issue every day in version 138.0.2 on an older computer running Windows 10. It's always been a bit slow, and Tbird would frequently get in a "not responding" state for a minute or two, but it didn't have this problem until recently, maybe v138 or v138.0.1. And sometimes after hitting OK for that message, the message list view would be empty and display "No messages", even though there are messages, and it would require restarting.

I just hit that issue again and in the console there's an error that might be related:

09:41:44.770 An error occurred updating the cmd_downloadSelected command: [Exception... "[JavaScript Error: "gViewWrapper.dbView is null" {file: "chrome://messenger/content/about3Pane.js" line: 6413}]'[JavaScript Error: "gViewWrapper.dbView is null" {file: "chrome://messenger/content/about3Pane.js" line: 6413}]' when calling method: [nsIController::isCommandEnabled]"  nsresult: "0x80570021 (NS_ERROR_XPC_JAVASCRIPT_ERROR_WITH_DETAILS)"  location: "JS frame :: chrome://messenger/content/globalOverlay.js :: getEnabledControllerForCommand :: line 49"  data: yes] globalOverlay.js:81:13

And then 1000s of warnings (there are a lot of emails in the Inbox) like this:

09:42:08.257 gloda.index_msg: Observed header that claims to be gloda indexed but that gloda has never heard of during compaction. In folder: imap://[redacted]@[redacted].com/INBOX sketchy key: 486001 subject: [redacted] IndexMsg.sys.mjs:1332:21

The first issue was just fixed in bug 1952311 comment 117 and the second one in bug 1963490.

Both of these are not the error message which is subject of this bug.

(In reply to Ben Campbell from comment #21)

The fix from Bug 1960105 is going into 139 and I'm reasonably sure this is the same issue.
139 is currently in the beta channel.

According to comment 24, bug 1960105 which is in 138.0.2 didn't fix the issue.

I have "Compact all folders when it will save over": "8 MB in total" enabled here. Today the error message almost always was shown on startup. Then I've compacted the folder manually and the error seems to be gone (at least for now).

Thunderbird 138.0.2 / Win11

1 POP3 account
1 IMAP account

Installed 139.0.
Still having the same error pop up.

Still seeing this error come up with version 139.